The Java™ Xlet application model was first introduced by Sun Microsystems in the Java TV™ application programming interface (API) for developing digital television applications for Java-enabled digital TV receivers. Java™ and Java TV™ are registered trademarks of Sun Microsystems, Santa Clara, Calif. In a digital TV receiver, several applications may be running simultaneously, such as an application for playing a game in conjunction with a game show and an application that shows program listings. Due to limited resources in the digital TV receiver, if a user is playing the game and decides to look at program listings, the game application needs to be temporarily paused to allow the program listings application to execute. Further, some of the resources used by the game application may need to be released to allow the program listing application to execute. The traditional Java™ application model is not ideally suited to this environment because in the traditional Java™ application model, lifecycles of applications are controlled by the applications.
In the Xlet application model, the life cycles of Xlets are controlled by an application manager that runs the Xlets. The Xlet interface provides four life cycle methods: initXlet( ), startXlet( ), pauseXlet( ), and destroyXlet( ). Thus, Xlets have four possible states: 1) a loaded state in which the Xlet instance is constructed but has not yet been initialized; 2) a paused state in which the Xlet has been initialized but is currently inactive; 3) an active state in which the Xlet is active; and 4) a destroyed state in which the Xlet has been terminated and is ready for garbage collection. When an Xlet is created by an application manager, the Xlet starts in the loaded state. The Xlet moves to the paused state after the application manager initializes the Xlet using the initXlet( ) method. At some point, the application manager may activate the Xlet by invoking the startXlet( ) method, at which time the Xlet activates the Xlet's user interface, obtains any system resources needed, and shifts to the active state. At any time, the application manager may deactivate the Xlet by invoking the pauseXlet( ) method, at which time the Xlet frees as many system resources as possible and moves to the paused state. The application manager may also destroy the Xlet at any time by invoking the destroyXlet( ) method, which moves the Xlet to the destroyed state.
Thus, if the game application and the program listing application are implemented as Xlets, an application manager in the digital TV receiver may use the life cycle methods of these Xlets to manage the interaction. When the user decides to look at program listings while playing the game, the application manager can pause the game Xlet and activate the program listing Xlet. If the user goes back to the game, the application manager can pause the program listing Xlet and activate the game Xlet.
Since the initial introduction of the Xlet application model, the model has been included in Java 2 Platform Micro Edition (J2ME™), a set of Java™ APIs for developing Java™ applications for resource-constrained devices such as cell phones, personal digital assistants, set top boxes and other consumer appliances. J2ME™ is a registered trademark of Sun Microsystems, Santa Clara, Calif. The Xlet application model is also included in other programming standards for limited-resource environments such as the Digital Video Broadcasting Project Multimedia Home Platform (DVB-MHP) programming standard.
In the digital broadcasting environment, many kinds of services may be introduced. In addition to the game playing example presented above, there may be services for tuning to internet broadcasts as well as to television broadcasts, chat services for communicating with other viewers, order placement services for placing orders for advertised products, a navigation service for navigating the available digital television services (e.g., program information), a teletext service for browsing pages of text and graphics, etc. Ideally, providers of the services would be able to implement service provider applications for use on set-top boxes from multiple manufacturers.
Service provider frameworks have been implemented for use in other Java™ environments based on the traditional Java™ application model to permit multiple providers of a service to provide the services in a standardized way. A service provider framework typically includes a set of interfaces and classes (usually abstract) (i.e., a service provider interface (SPI)) for a type of service (e.g., a cryptography service, a naming service, a directory service, etc.). A provider of the type of service represented by the service provider framework (i.e., the service provider) is required to implement the defined interfaces and classes as part of the implementation of the service in order to provide the service to Java™ applications. Java™ applications may then directly share instances of the implemented service provider and may use the service through the defined interfaces.
Service provider frameworks are currently not available for use in an Xlet application model. In the Xlet application model, an Xlet is not permitted to directly share mutable object instances with other Xlets, whereas sharing of instances of a service provider is required in known service provider frameworks.